Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.33%. Comparing base (ce027fd) to head (b3249c5).
Report is 1 commits behind head on main.

@@           Coverage Diff           @@
##             main      #10   +/-   ##
=======================================
  Coverage   83.33%   83.33%           
=======================================
  Files          13       13           
  Lines         414      414           
=======================================
  Hits          345      345           
  Misses         69       69           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Thanks @ogauthe. Another way I could picture designing this would be making this gradedrange constructor in GradedUnitRanges.jl: https://github.com/ITensor/GradedUnitRanges.jl/blob/dedd27a2a5c560f4bb0156b0347679f654a224e6/src/gradedunitrange.jl#L95-L99 more generic, for example:

function gradedrange(lblocklengths::AbstractVector{<:LabelledInteger})
  brange = blockedrange(unlabel.(lblocklengths))
  lblocklasts = labelled.(blocklasts(brange), to_sector.(label.(lblocklengths)))
  return GradedOneTo(lblocklasts)
end

to_sector(x) = x

and then GradedUnitRanges.jl could have a package extension GradedUnitRangesSymmetrySectorsExt that overloads to_sector:

module GradedUnitRangesSymmetrySectorsExt

using GradedUnitRanges: GradedUnitRanges
using SymmetrySectors: SectorProduct

GradedUnitRanges.to_sector(nt::NamedTuple) = SectorProduct(nt)

end

That would be more generalizable and a bit simpler since it just keeps a single gradedrange constructor.

(Closed and reopened to retrigger the tests now that ITensor/GradedUnitRanges.jl#17 is merged.)